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@ Update constraints in transactions which may abort 

@ A technique,which may be used In a transaction which updates a data set when the data set is subject 
to constraints and includes operations which may abort, produces an update constraint which may be 
tested before the data set is altered to detemiine whether the constraints wDI be satisfied if the data set 
is altered. The update constraint of the technique indicates whether the constraints would be satisfied if 
the transaction could not abort. The update constraint is checked at the application level, while the 
constraints which cause an operation to abort are checked at the system level. An applicatkin of the 
update constraint to a relational data base embedded in a telephone switch Is disdosed. 
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1 Background of the Invention 

1.1 Field of the Invention 

5 The invention concerns systems in general in which operation of the system is subject to constraints and 
particuiarty concerns constraints Involved In maintaining the integrity of data in a data base system. 

1.2 Description of the Prior Art 

10 An Important operation In data base systems is changing the data in the system. Operations which change 
data may involve adding data, deleting data, or updating data, which Is a combination of deleting and adding. 
In the following, operations which change the data base are termed generally update operations. 

Care must be taken in an update operation that the data being added to the data base system does not 
compromise the integrity of the data in the data base system. For example, a data base of employee Infomiation 

15 may have a record for each employee which Includes fields specifying the employee's grade and pay. Pay 
may be coupled to the grade, so that it must be above a minimum and below a maximum specified for the 
grade. In such a data base, maintaining the Integrity of the data base system requires that when a new em- 
ployee record Is added or an existing record is altered, the data base system check whether the pay In the 
new or altered record is within the range specified for the grade. A condition which must be met by data which 

20 Is to be Included In a data base In order to maintain the integrity of the data base is termed a constraint, and 
in many data base systems, any update operation includes a phase called constraint checking. In which the 
data base system determines whether the constraints required for the operation are satisfied. 

One way of doing constraint checking is to do the operation, check any constraints, and if a constraint 
has been violated, undo the update, l-lowever. it is usually possible to determine whether the constraints will 

25 be violated before the update is made and do the update only If there Is no vkilatlon. 

Of course, constraint checking takes time, so it Is important to do as little as possible of it. In many cases, 
constraints are dependent on other constraints in such a fashion that only a few of the constraints actually 
need to be checked. A smaller set of constraints which can be checked with the same results as checking all 
of the constraints is termed an update constraint. One way of finding an update constraint is to calculate a 

so logical fonmula called the weaAresf preconcBtion of the entire set of constraints with regard to the update. The 
weakest precondition sets forth a set of constraints which must be true If the entire set of constraints is to be 
true after the update has been perfonned. See CAR. Hoare, "An axiomatic basis for computer progranruning," 
In: Communications of the ACM 12(10), October 1969. 

However, even testing the constraints of the weakest precondition may Invoh^e more worlcthan necessary. 

35 As set fbrth in X. QIan, "An effecth^e method for Integrity constraint simplification". In: Fourth International 
Conference on Data Engineering, 1988, it is possible to take advantage of the fact that the constraints are 
known to hold In advance. Since that Is the case, the weakest precondition can be factored Into a first portion 
of the weakest precondition which is implied by the constraints and a second portion which Is not The AND 
of these portions Is logically equivalent to the weakest precondition, and consequently. It possible to check 

40 the wealcest precondition by checking the second portion only, and the second portton by Itself can thus func- 
tion as the update constraint. 

A problem with the foregoing work on update constraints involving the weakest precondition and QIan's 
further simplification thereof is that it does not take into account the fact that in practical data base systems, 
certain of the data base system operations which are executed in the course of an update operation may them- 

45 selves abort, that Is, they may terminate without affecting the data base if certain constraints i mposed by the 
data base system are not satisfied. For example, the data base system Insert operatton which actually inserts 
a new record into a data base requires that the new record be in fact new, itdetermines this by checking whether 
a key which Identifies the record to the data base system is the same as that of any existing record in the data 
base; if it is. the insert operation aborts. The constraints which these operations must satisfy are different from 

50 those required to keep the content of the data consistent, and it has heretofore not been apparent how to in- 
corporate such constraints into update constraints. 

2 Summary of the Invention 

85 The inventors have discovered that all that Is necessary to solve the problem of update constraints in systems 
which have operations which may abort is to determine the update constraint using the assumption that the 
transaction cannot abort In one aspect of the Invention, the discovery is used in methods and apparatus for 
generating code for transactions which incorporates update constraints determined as describe above. In an- 
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other, such update constraints are used in methods and apparatus for performing update transactions. An ad- 
vantage of such update constraints is that the checks for the constraints which cause the system to abort the 
operation are performed at the system level, while those for the update constraint are performed at the appli- 
cation level. 

5 Other objects and advantages of the apparatus and methods disclosed herein will be apparent to those 
of ordinary skill in the art upon perusal of the following Drawing and Detailed Description, wherein: 

3 Brief Description of tlie Drawing 

10 FIG. 1 1s an overview of a data base system tn which the invention may be employed; 

FIG. 2 shows two relations employed in an example; 
FIG. 3 shows constraints employed in the example; 

FIG. 4 is a block diagram of apparatus for generating update code according to the Invention: and 
FIG. 5 Is an example of update code generated for the example. 
15 Reference numbers In the Drawing have two parts: the two least-significant digits are the number of an 
item in a figure; the remaining digits are the number of the figure In which the Item f Iret appears. Thus, an Kern 
with the reference number 201 first appears in FIG. 2. 

4 Detailed Description of a Preferred Embodiment 

20 

The following discussion will begin with an example of the invention; there-upon, a precise logical definition 
of the invention wilt be presented. 

4.1 Overview of a Data Base System: FIG. 1 

25 

FIG. 1 shows a typical data base system 101. The hardware components of system 101 are a processor 111 
which can execute computer programs, mass storage device 119, on which data is stored, and user interface 
103, which includes a display, a keyboard, and a pointing device such as a mouse. 

System 101 results from the execution of the code for a data base management system 113 on processor 

30 111 . Data base management system 1 1 3 organizes the data In mass storage 11 9 into a set of relations. Each 
relation is a table which has columns and rows. The columns define classes of data (for example, employee 
name, employee department, and pay), while the rows contain related values of the data, for instance a specific 
employee name and the specific values for employee department and pay which go with that employee name. 
There are two kinds of relations in data base system 101: base relations 121. in which the data values are 

as actually stored in mass storage 119. and views, that Is. reiatlons which do not really exist In mass storage 119 
but are constructed on the fly from data in base relations 121. 

Data base management system 113 manipulates the data in response to transaction specifications 105 
which specify transacttons on the data in the data base system. The transaction specifications are provided 
by users of the data base system. The transaction specifications, specify operatkins on the relations such as 

40 reading data from a relation or writing data to the relation. Data base management system 113 responds to a 
transaction specification 105 by invoking data base management system primitive routines 116 as needed to 
perform the operations 117 on mass storage device 119 required to execute the transaction; if the transaction 
succeeds, the result is returned to the user Interface, as Indicated by arrow 107; otherwise, an enw message 
109 is returned. 

45 As pointed out In the Description of the Prior Art, one Important dass of operations specified by transaction 
specif iere is update operations, in which the data in relations 121(a) Is altered. The part of data base manage- 
ment system 115 which performs update operations appears in FIG. 1 as update code 115. As also pointed 
out In the Description of the Prior Art, when a transaction involves an update of data in relations 1 21 , data base 
management system 1 1 3 must ensure that the update does not degrade the Integrity of data base system 101, 

80 and consequently, part of the task of update code 11 5 is to check whether update constraints have been vio- 
lated. If they have been, update code 115 does not change the data in relations 121, but instead returns an 
error message 109. Transactions involving updates are termed in the following update transactions. 

4.2 An Example Update Transaction: FIGS. 3-5 

55 

In the following, a simple example will be presented to show how weakest preconditions may be used to 
do constraint checking in data base system 101. The example involves two relations 121. The relations are 
shown In FIG. 2. The firat relation Is employees relatton 201, which has a row 203 for every employee. The 
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columns of the relation are name 205, for which the values are employee names, sal 207, for which the values 
are employee salaries, and dept. for which the values are department numbers. Thus, each row 203 specifies 
an employee's name, his salary, and his department number. As indicated by the underline, the name field 
functions as the key for each record, that is, the record is identified to data base management system 11 3 by 
5 the value of name. 

The second relation is departments 211, which has a row 213 for each department in the business. The 
columns are dept 215, whose value is the department number, and manager 217. whose value is the name of 
the manager. The key in departments 211 is dept 215. Departments 211 and employees 201 are related to 
each other by way of the keys. For example, the manager whose name appears In manager column 21 7 for a 

10 given row 21 3 of departments 211 also has an entry under his name in employees 201 . Because the key of 
one relation is used as data In the other, the data base management system can construct views which contain 
Information from both relation 211 and relation 201. One example of such a view Is a relation which has an 
entry for each manager and which specifies the manager's name, department, and salary. In making the view, 
data base management system 113 retrieves the manager's name and department from departments 211 and 

15 uses the manager's name in employees 201 to retrieve the value of the manager's salary from column 207. 

Even in the two relations 211 and 201, there are a number of constraints on the values of the rows. FIG. 
3 shows these constraints 303, expressed in the notation of logic. Constraint 303 states that for all employees 
in relation 201 , the salary must range between two values specified by min and max. Constraint 305 specifies 
that for all employees, the department number in column 209 must be one of the department numbers in de- 

20 partments 211 . Constraint 307 says that for every row in departments 211 . there must be a row in employees 
201 such that the value of manager equals the value of name and the value of dept in the row of employees 
201 equals the value of the same field in the row of departments 211 . Constraint 309, finally, says that for all 
employees St. all employees ez. and all departments, if the two employees are in the same department and 
employee ez is the department manager, employee e^'s pay must be less than or equal to employee e2's pay, 

25 or in other words, that no employee's pay may be higher than that of his manager. 

Whenever an update operation is performed on relation 201, relation 211, or any on any view where the 
view is derived from relation 201 or 211 and the change Involves a value of relation 201 or 211, a constraint 
check must be made to ensure that none of the constraints of FIG. 3 is violated. This constraint check is per- 
formed by update code 115. FIG. 4 shows how update oodejnduding the proper constraint check Is generated. 

30 Constraints 301 and a transaction descriptor 403 which describes a class of transacttons are input to update 
code generator 405, which generates update code 115 for the transaction described by descriptor 403. Update 
code 115 includes update constraints 407, which are checked whenever a transaction belonging to the class 
described by descriptor 403 is performed to make sure that the transaction Is not violating one or more of the 
constraints 301. 

38 FIG. 5 gives an example of how update code 11 5 is generated from con-straints 301 and a transaction 
description 403. Transaction description 403 defines a class of him transacttons 501. In this transaction, done 
when a new employee is hired, a row 203 containing the new employee's name, salary, and department number 
is added to employees 201. The nanrte of the new employee is represented in the transaction description by 
the parameter n, the salary by the parameters, and the department number by the parameter dp. As Indicated 

40 by the = symbol, the transaction descriptton defines the hire transaction by equating it to a sequence of state- 
ments in a a transaction language which describe the transaction. 

In the example, only a single statement is required, namely an insert statement 503. Insert statement 503 
specifies that a row 203 is to be Inserted in employees 201, and that values are to be supplied for all three 
fields of the row. The order of the values corresponds to the order of the fields of the row. When update code 

45 generator 405 receives transaction description 403, it uses transactton descriptton 403 and constraints 301 
to generate update code 513. Update code 513 contains update constraint 51 5. which is an update constraint 
407 which embodies the principles of the invention. 

Inserting a row in employees 201 requires the use of the insert operation 509. one of the primitives 116 
provided by data base management system 113. A property of //iserf operation 509 is that it aborts if the key 

50 of the row being added to the relatton is the same as a key for a row which is already In the relation. Thus, If 
insert 503 is used to insert a row in relation 201 which has a value for n (representing the name) which is the 
same as a value for name field 205 in another record of employees 201, insert 509 will not alter employees 
201. 

In accordance with the principles of the Invention, constraint 515 does not reflect the constraints which 
S5 data base management system 11 3 requires fbr insert operatten 509. Instead, update constraint 51 5 includes 
only those constraints which nnjst be checked if insert operation 509 does not abort. Thus, none of the con- 
straints in update constraint 515 deal with the relationship of the key 205 of the new row 203 to the keys 205 
of the other rows 203 of employees 201. Update code generator 405 generates such a constraint 515 because 

4 
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/nserf statement 503 is one of a dass of expressions in the language used for the transaction description whose 
evaluation requires that data base system 101 execute an operation which may abort In FiG. 5, update con- 
straint 515 is checked before the insert operation is performed; if the constraints of 515 are not satisfied, an 
error message 511 is returned by update code 115; if they are satisfied, insert operation 509 is executed, as 
5 indicated at the next to the last line. If Insert operation 509 Is successful, the new row is added to employees 
201; if it aborts, portion 116 of data base management system 113 which handles primitive operations returns 
an error 119. 

In morB detail, update constraint 515 requires that the following be true before insert 50Q is executed: 

• the salary specified for the new row is In the allowed range; 

10 • the department number specified in the new row is the same as that of one of the departments of relation 
211; and 

• the salary specified for the new row is no more than that of the new employee's manager. 

As may be seen by comparing the above constraints with the full set of constraints 301 , update code generator 
405 has transformed the full set of constraints into exactly those constraints which must be true before the 
18 specific transaction of adding a row to table 201 can be done. 

4.3 Logical Description of the Technique 

The fbllowing Is a logical description of the technique of finding an update constraint in the presence of oper- 
20 ations which may abort. The description begins with a definition of a simple transaction language which pro- 
vides a logical description of the transactions for which the weakest precondition is to be found. Of course, 
the technique is not limited to this language and may be applied with far more complex transaction languages. 

4.3.1 Description of the Transaction Language 

26 

Simple updates }i are given by the grammar 

fi ::= insert(r,ai = <i,...,af = *i) 
^ I delete(r,6i = <x,...,6,=<,) 

and transactions B are defined to be sequences (blocks) of simple updates. 

^ B ::= simple update 

I ; B sequence 

^ The abbreviations insert(r. a =t ) and delei8(r, S =» T ) will often be used. A simple update in8ert(r. 

a s r ) Is well-fonned (with respect to the data base scheme) when a • are the attributes of relation r and 

the termes off contain no free record variables. If {ki..... is the key for r, then deletB(r, ^ fi bj » fj) 

45 la weil-fbnned when {ki s {b^ bj^ and the terms of i contain no free record variables. A transaction 

fi Is well-formed if all of the simple updates comprising it are weli-fbmied. 

Transactions 8( u ). having all scheme variables among the variaUesu . will be referred to as transaction 
schemes. Given tenns t » fi U an instance of such a scheme is written as B(t ). 

50 

Infbrmally. Insert(r. a^t ) Inserts the record <a -t > Into rsiatton rand delet8(r..S = t ) deletes 

the recort t in r with t.6 = f . The insert operation aborts if the insertion would result in duplicate keys, and 
the delete operation aborts if there is no record to be deleted. Asequence B aborts when any of its component 
55 updates aborts. The aborting semantics of the delete update is meant to nwdel the semantics of the our cun-ent 
application. It is easy to modify our presentation to accomnxxfate a delete that does not abort In any case, it 

we can formally define the semantics of transactions as a state-valued function h^B{ u )Tips that takes a 

5 
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transaction scheme 6( u ). a state 5, and a substitution p covering the variables u as arguments. 

Assume we have a transaction B, formulas a and p, and a substitution p that covers fi, a and ^. The formula 
p Is a precondition of a w.r.t 8 and p if for all database states, s, s,p » p. implies that M[[B]]ps. p » a - that is. 
If p holds before the execution of B, then a will hold afterwards. A formula p is called a weakest precondition 
ofaw.r.t. B when ^ is a precondition of a wxt B and for all database states s. If M[[B]]ps. p » a, then s.p - p. 
In other words, if p is a weakest precondition of a w.r.L 8. then s,p » p If and only if M[[6]]ps,p » a. 

4.3.2 Definition of the Weakest Precondition 

The Invention defines a particular wealcest precondition of a formula a which represents with respect to a trans- 
action 8, wpc(a, 8). Ordinarily, we might expect that 

wpc(a,|i;8) = wpc(wpc<a,e),ji) 
reflecting a compositional semantics for sequencing. However, this definition Is not consistent with our semant- 
ics since either ^ or 8 may abort with the result that \i; B aborts with no change to the database. In the case 
of an aborting transaction the weakest precondition should simply be a, or some equivalent formula. 

This can be expressed by defining a predicate N(S} (pnsnounced 8 is nice) that Is true if and only If 8 does 
not abort We then define a composlttonal wpcb(a, 8) for transactions 8 that do not abort A weakest precon- 
dition can then be defined as 

wpc(a,S) = (A/(fl) A wpc„(a,S)) v {1N{B) a a), 
which says that either 8 is nice and wpC|,(a, 8) holds or 8 will abort and leave the state unchanged. 
The fbrmulas N(B) and wpc„(a. 8) are defined as 
1. 

^'(delete(^, 6 = 0) = 3* € r x.b = t 

2. N(»n8ert(r. ki = fi k„ = fm—a/ » 0) = V x g r x.ici * fiv v x.k„, ^ t„ 

(where {k^ ic^} is the key of r.) 

3. W(n ; 8) = Niix) A wpc,(W(B).^) 

where wpc,(a.^) is a weakest precondition for simple updates, defined by racursion on the structure of a as 

1. wpc.(/,n) = / 

2. wpc,(a A = wpQi^a,ji) a wpcO,n) 

3. wpc^a V = wpc^o,n) V wpp.O,|i) 
4. 



S5 



40 



wpc,(Vi€ra(a:),/i)=: 

wpc,(a((a - A Vx € r wpc,(a(x), /i) if = insert(r,a = 0 



V* 6 r x.6= fv wpc,(a(a:),/i) 
Vx€rwpc.(a(x),^) 



if =delete(r,fr = t) 
otherwise 



5. 



45 



50 



wpc,(3x€ra(x),;i) = 

' wpc,(at((a = t)), /i) V 3x € r wpc,(a(x), /i) if /i = inscrt(r, a = t) 



3x e r x.6^ Ta wpc,(a(x),;i) 
. 3x€rwpc,(a(x),Ai) 



ifp = delete(r,6=se) 
otherwise 



5S 



and 



1. wpc^o.ji)'wpc,(a,n) 

2. wpc„(a. II ; 8) » wpc,(wpc„(o, 8). »i) 
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4.4 Example Industrial Application of the Technique 

The technique described above has been used to maintain the data integrity of an embedded relational data 
base in the 5ESS switch manufactured by AT&T Corp. (5ESS is a trademark of AT&T Corp.). The data base 

5 contains information concerning telephone customers, switch configuration, and network topology. Data In- 
tegrity is crucial for the proper functioning of the switch since all application programs - performing tasks such 
as call processing, switch maintenance, and billing • are driven from information in the database. 

The 5ESS database is large and complex, containing nearly one thousand relations. The switch developers 
had been dealing with the integrity problem in two ways: by continually auditing the data base and by writing 

10 "safe' transactions. The auditing was done by a program which ran continually and reported errors as it fbund 
them. The code for the program was generated using a formal language for declaring static integrity constraints 
- a variant of the tuple relational calculus with range restrictions. These integrity constraints involved tens of 
thousands of integrity assertions, some very complex. 

A safe transaction is one which will never result In a violation of the integrity constraints. The process of 

15 writing safe transactions for the 5ESS switch required enonmous effort and was prone to error. It involved the 
tasks of (1) writing an initial transaction in C using a low-level interface to a database manager, (2) locating 
and understanding the relevant integrity constraints, (3) determining which checks had to be made to ensure 
data integrity, (4) encoding these checks In C and inserting them into the transaction. Over a half million lines 
of transaction code have been handwritten in this way. 

20 The techniques described above have been used to partially automate the process of writing safe trans- 
actions. We eased the burden of step (1 ) by replacing C with a high-level transaction language, and we replaced 
steps (2 - 4) with a code generator which automatically generates code for a safe transaction from a transaction 
description in the transaction language. 

Our transactton language is based on QIan's first-order transactions, see XIaolei Qian, "An Axiom System 

25 for Database Transactions', information Processing Letters, 1990, vol. 36. pages 183-189. The first-order 
transactions include the basic operations of insert, delete, and update together with control constructs for se- 
quencing, conditionals, and a restricted form of itera-tion. The code generated from the transaction language 
and the constraints for the switch has embodied the invention described above, and has thus efficiently spe- 
cified safe transactions. Use of the transaction language has guaranteed correctness, has reduced the amount 

30 of code which the switch developers must write, and has reduced the time required to define a new transactton. 
Parts A, B, and C of the Appendbc of the present application provide an example of the application of our 
techniques in the 5ESS switch. Part A of the Appendix is the constraints which apply when a row is inserted 
Into a particular one of the relations In the data base. Part B is the transaction description for the operation of 
Inserting the row into the rslatton. Part C Is the insertion code generated from the constraints of part A and 

55 the transaction descriptton of part B. It should be pointed out here that the insertion code has the same general 
form as the code in the example of FIG. 5; the update constraints are enclosed between verify and end verify 
and the primitive /nsert operations follow the update constraints, for example Insert tRIoscdb in Rloscdb in the 
ninth line of Part C. 

The N predicates discussed until now have had the relatively simple semantics of typical data base system 
40 insert operations. There is, however, no requirement of simplicity. Part D of the Appendbc Is a complex example 
N predicate. The N predicate is expressed in the declarative transaction description language used in the ex- 
amples for the 5ESS switch and involves checks for key conflicts in two different relations as well as for legal 
Indices In the second relation. If the checks are passed, the predicate specifies that a row is to be located in 
a third relation. The N predicate of Appendbc D can reflect the semantics of a system-level operation, as is the 
45 case with the N predicates for the Insert and deiete operations in the data base system in the SESS switch, 
or ft can be semantics which are expressly defined for a statement in the transaction description language. An 
example of a statement in the transaction description language for which N semantics are expressly defined 
is the abort statement at the bottom of the first page of part B of the Appendix. 

50 5 Conclusion 

The foregoing Detailed Description has disclosed to those skilled In the art how update constraints may be 
employed to insure integrity In systems having operations which may abort and has shown how such update 
constraints may be employed in an industrial application. Use of the techniques is not limited to the data base 
55 systems disclosed herein. Rather, the techniques can be used in any application where a possible alteration 
Is subject to constraints. For instance, the techniques might be used to verify that a modification to a computer 
program conforms to the requirements of the context in which it is made. It is furthermore apparent from the 
Detailed Description that the technique Is applicable with many different ways of specifying constraints, trans- 
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actions, and actual operations on tfie data base system. 

All of the above being the case, the foregoing Detailed Description is to be understood as being in every 
respect illustrative and exemplary, but not restrictive, and the scope of the invention disclosed herein is not 
to be determined from the Detailed Description, but rather from the claims as interpreted according to the full 
breadth permitted by the law. 
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Appendix 

A Constraints 

/* RULE about RLosc2oap . attr.valnes «/ 

for t in IU.osc2oap 
begin 

/* validate osc.ntui vith RLoscdb */ 
find 1 osc in RLoscdb vhera 
(osc . osc.nuB «■ t . osc.nua) ; 

/* validate oap.nuffl vith RLoapdb */ 
find 1 oap in RLoapdb vhere 
(oap . oap.nna t . oap.num) ; 

ao /* no duplicates allowed */ 

find 0 dup in RLosc2oap where 
(dup.osc.nuffl t.oscniu kk 
dttp.oap.niui t.oap^nttn kk 
dap.oap.idx !■ t.oap.idx); 

35 

* NOTE: 
* 

40 * There are no holes allowed in oap.idz 

* (i.e. if t exists with t. oap.idz 3 

* for some t.osc.nuffl, then t's also 

« exist for oap.idx 0,1, and 2 vith 
« this 08C.nua 
« ♦/ 
end 

/♦ RLDSP.MSGS is to be populated fron HDD so this file can be fempty-ed. */ 

80 
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/* RULE about RLospsparm.attr. values */ 

for ospsparn in RLoapsparn 
begin 

ospsparm.ofc.type is.in {"0"}; 

if (ospsparn. of c.type «- "0") then 

ospsparm.ofc.nuni is.in {1 thru 32}; 



ospspara.ofc.oap is.in {DBYES}; 
ospspara. of c .thresh is.in {0 thru 6>; 
ospsparn. sofc.typ is.in {"0", ""}; 
ospsparn. sofcnu is.in {0 thru 32}; 
ospsparn. gdport2. module is.in {0}; 
ospsp arm. gdport 2. member is.in {0}; 
20 ospsparm. gdport. member is.in {$GLMNPOBT thru SGLMXPORT}; 

/* RULE about sofc.type */ 
combinat ions .of 
25 (ospsparn. of c.type, ospsparm. of c.num, 

ospsparn. sofc.typ, ospsparm. sofc.nu) 

begin 

"0", {1 thru 32}, "0", {1 thru 32}; 
30 "0% {1 thru 32}, 0; 

end 



/* The secondary office specified in a tuple nust 
* exist as a primary office in ANOTHER tuple 



find 1 TUP in RLospsparm 
vhere( (ospsparm . sofc.typ TUP.ofc.type kk 

ospsparm. sofcnu » TUP.ofc.num) 
(ospsparn . of c_ type ! » TUP . of c.type 1 1 
ospsparm. of c.num !« TUP.ofc.nun) ) 
^ vhen.found 



so 
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begin 

TUP.sofc.typ — 
TUP.sofc.nu «» 0; 

end 



* For any given RLospsparm OSC-tuple, the secondary 
* office cannot be the same as the primary office 
*/ 

! (ospsparm.sof c.typ ospsparm.ofc.type kk 
ospspauna.sofc.nu == ospsparm.ofc.num); 

/* RULE about sof c.nu */ 
^ combinations. of 

(ospspazn.ofc.type, ospsparm.ofcnum. 
ospsparm . sof c.typ , ospsparm . sof c.nn) 
begin 

» «0", {1 thru 32}, "0", {1 thru 32>; 

"0", {1 thru 32}, "", 0; 
end 

30 /* Tlie secondary office specified in a tuple must 

* exist as a primary office in ANOTHER tuple 
*/ 

if (ospsparm. sofc.nu !» 0) then 
find aa 1 TUP in RLospspam 
vhereC (ospsparm. sofc.typ — TUP.ofc.type 
ospsparm. sofcnu «» TUP.ofcnum) kk 
^ (ospsparm. of c.type !- TUP.ofc^type II 

ospsparm. of c.num !■ TUP.ofc.num) ) 
vhen.f ound 
begin 

TUP.sofc.typ kk 
^ TUP.sofc.nu 0; 
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/♦ 

« For any given RLospsparm OSC-tuple, the secondary 
*. office cannot be the same as the primary office 
♦/ 



! (o8pspara.8ofc.typ ■« ospspam.ofc.type kk 
O8p8para.8ofc.nu — ospspara.ofc.nua); 

IS /* RULE about gdport .module */ 
combinations. of 
(ospspara. gdport .module , ospspam . gdport .member) 

begin 
0. 0; 

{1 thru 192>, {$GLMNPORT thru $GLHXPORT}; 

end 



/* 

* IF the port exists it must be on an OSPS SH 
*/ 

if (ospspara. gdport. module !■ 0) then 
begin 

^ find 1 modatt in RLmodatt 

vhere (ospspara. gdport. module •» modatt. module kk 
modatt . osps.sffl DBYES); 

35 /* 

* There can be no more than 4 OAPs per SM. Hatch 

* 3 tuples other than this tuple on the same SM 

* (Note: RLospsparm. gdport. module is not null 
♦/ 



find < 4 TUP in RLospsparm 

vhere (ospsparm. gdport. module ■« TUP. gdport .module ftft 
ospspara . gdport . aember ! ■ TUP . gdport . member) ; 
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/♦ 

• The servclass attribute of this port in RLfc.porCtyp 

m must be AS.OAP. 

*/ 



find ■- 1 fc.porttyp in RLfc.porttyp on ospspara.gdport .fflodnle 
where (ospspaiTB.gdport ■■ fc.porttyp.port kk 
fc.porttyp.port.indx «- $GLDCH kk 
« fc.porttyp . servclass AS.OAP); 

end 



/♦ RULE about evat.rpt •/ 

if (ospsparm.evnt.rpt »- DBYES) then 
begin 

ospsparm.sofc.typ !- kk 
ospsparm.sofc.nu O; 

end 



/♦ RULE about ofc.dcq, ofc.dst, ofc.dpos ofc.dop, ofc.prfl, 

* ofc_prf2, ofc.prfS, ofc.prf4, ofc_prf5, ofc_«itltr24, 

* ofc.wnt2tr24, ofc.TOt3tr24, of c«wnt4tr24, ofc.vnt5tr24« 

* ofc.prfop 

* of c.piDl must be DBYES 

* of c_pm2 oust be DBYES 

* of c.pin3 must be DBYES 

* of c.pm4 must be DBYES 
^ * of cpmS must be DBKO 

* If ofc.pnop is DBNO, ofc.prfop must be DBHO 

* ofc.pmltr24 must be DBNO 

* of c.pm2tr24 must be DBNO 
^ * of c.pm3tr24 must be DBNO 

« of c.pm4tr24 must be DBNO 

* of c.pm5tr24 must be DBNO 
♦/ 

if (ospspara.ofc.oap ■> DBNO) then 
begin 
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ospsparm.ofc.dcq » DBNO; 
ospsparm.ofc.dst » DBNO; 
ospsparm.of c.dpos » DBNO; 
ospsparm.ofc.dop DBNO; 
end 

ospsparm.ofc.pml DBYES; 
ospsparm.ofc.prf 1 DBYES 
08psparm.ofc.pB2 DBYES; 
08p8parm.ofc.prf2 DBYES 
ospsparm . of c.pmS " DBYES; 
ospsparm.ofc_prf3 « DBYES 
ospsparm.ofc.pm4 " DBYES; 
ospsparm.ofc_prf4 « DBYES 
ospsparm.ofc.pmS °» DBNO; 
o8p8parm.ofc.prf5 ^ DBNO; 
08psparm.ofc_pnltr24 DBNO; 
ospsparm.ofc.viitltr24 » DBNO; 
08psparm.ofc_pm2tr24 DBNO; 
ospsparm.ofc.wiit2tr24 =- DBNO; 
ospsparm.ofc.pffl3tr24 DBNO; 
o8p8parm.ofc.vxLt3tr24 » DBNO; 
osp8parm.ofc.pm4tr24 «= DBNO; 
ospsparm.ofc.¥iit4tr24 DBNO; 
08psparm.ofc_pm5tr24 DBNO; 
08psparm.ofc.viit5tr24 DBNO; 
if (ospsparm.ofc.pfflop 
begin 

ospsparm . of c.prf op 



DBNO) then 
" DBNO; 



end 



end 
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/* RULE about RLoscdb . attr.values «/ 

for oscdb in RLoscdb 
begin 

oscdb . osc.nnm is.in {1 thru 128}; 
oscdb. Bon.ndcator is.in {DBYES, DBNO}; 
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end 

/* RULE about RLoapdb . attr.values */ 

for oapdb in RLoapdb 
begin 

oapdb . oap.num is. in {1 thru 8}; 

oapdb. port is.in {$GLMNPORT thru IGLMXPORT}; 

/* RULE about gdport .module *l 
combinations.of 
(oapdb . nodule , oapdb . port ) 
begin 

{1 thru 192). {$GLMNPORT thru $GLMXPORT}; 

end /* combinations.of (*oapdb. module. . «/ 

/* The port must be on an USPS SM «/ 
find as \ modatt in RLmodatt 
where (oapdb. module modatt .module kk 
modatt . osps.sm — DBYES) ; 

/« There can be no more than 4 OAPs per SM */ 
find < 4 TUP in RLoapdb 
vhere (oapdb. nodule TUP. module kk 
oapdb. port TUP. port); 

/* 

• The servdass attribute of this port in RLf c.porttyp 

* must be AS.OAP. 
♦/ 

find 1 f c.porttyp in RLf c.porttyp on oapdb. module 
where (oapdb. port »■ f c.porttyp. port .member kk 

oapdb. module ** f c.porttyp. port. module hk 

f c.porttyp. servclass AS.OAP); 



end /* for oapdb in RLoapdb «/ 



14 



Page 15 of 22 



EP 0 689 136 A1 



10 



15 



26 



30 



38 



B The INSERT Transaction Description 

insert-rules : 

Insert Case 

insert oscdb in RLoscdb 
begin 

oscdb. osc.nun ■ nev.viev.osc^um; 
oscdb. fflon.ndcator ■ netf.viev.Bon.ndcator; 
end 



for i in it thru HAXLIST} 
begin 

/* check if oap.num has been entered on the viev «/ 
20 if (nev.viev.nulls.oap.nunCi] !> NVZ) then 

begin 

/* check if the oap.num entered is valid «/ 
find capdb in RLoapdb 

vhere (oapdb . oap.nun "« nev.viev.oap^umCi]) 
vhen.found 
begin 

insert osc2oap in RLosc2oap 
begin 

osc2oap.osc.niiiii ■ nev.viev.osc.nuffl; 
08c2oap.oap.idx « i; 
osc2oap.oap.nua « nev.viev.oap.numCi] ; 
08c2oap . evnt " new. viev . evnt [i] ; 
end 
end 
else 
begin 

^ abort (CstmErr); 

/* RCEHRlOl; */ 

/♦ INPUT DATA ERROR */ 

/* OAP NUH entered does not exist (OSOAP) . */ 
45 end 
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end 
end 



C Generated Code for INSERT 



10 



15 



insert-rules : 
begin 

begin 

verify 

nev.viev. osc_nim>"l ; 
nev.viev . osc.niui<"128 ; 

nev.viev. mon^dcator—DBHQ 1 1 nev.viev. mon.ndcator«>DBYES; 
endverify 

^ insert tRLoscdb in RLoscdb 

begin 

tRLoscdb. osc.num « nev.viev. osc.num; 
tRLoscdb.Bon.ndcator " nev.viev. mon.ndcator; 

end 

end 
begin 

verify 

for t in RLo8c2oap 
begin 

for i in {1 thru HAXLIST} 
vber e (NVZ ! 'nev.viev . nulls . oap.num Ci] ) 
begin 

let gO() - 

for oapdb in RLoapdb 

begin oapdb . oap.nun ! -nev.viev . oap.nuB Ci] ; end 
if (i! "t.oap.idx) tben 

nev.viev. 08c.nun! at. oscnua tl 
t . oap.num ! "nev.viev . oap.nun Ci] 1 1 

gOO; 

end 

end 

4$ 
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endverify 

for i in {1 thru MAXLIST} 

5 begin 

if (NVZ !«ne«.viev. nulls. oap.nua[i]) then 

begin 

let glO - 

find > 0 oapdb in RLoapdb 

where (oapdb . oap.num-«new_vietf . oap.nuB [i] ) ; 

verify 

if (glO) then 
begin 

IS for i_ in {1 thru HAXLIST} 

where (NVZ ! -new. vi ew . nulla . oap.num Ci.] ) 
begin 

if (nev.view . o ap.num [i] — new.view . oap.num Ci J ) then 
i»-i-; 

end 

for dup in RLosc2oap 
where (dup.osc.nuin=»new,view.o8C.nun kk 
dup . oap.num°"new.view . oap.nua Ci] ) 
25 begin i""dup.oap.idz; end 

end 

endverify 

find oapdb in RLoapdb 

where (oapdb . oap.num»-new.view . oap jium Ci] ) 
when.found 

insert tRLosc2oap in RLo8c2oap 

begin 

tRLosc2oap. oap.num - new.view. oap.num Ci] ; 
35 tRLo8c2oap.08C.nua - new.view. oscnua; 

tRLo8c2oap.oap.idz ■ i; 

tRLo8c2oap . evnt - new.view . evnt Ci] ; 

end 

el8e 

abort (CstoErr) ; 

end 
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end 

end 

D Example NICE Predicate 

/* no key conflict */ 
for oscdb in RLoscdb 
begin 

oscdb. oscnum !- new.viev.osc.ntu!; 
end 

for i in {1 thru MAXLIST} 
begin 

if (nevJviev.nnlls.oap.nnnCi] !■ NWZ) then 

begin 

/♦ no key conflict */ 
for osc2oap in RLosc2oap 
begin 

08c2oap.osc.num !* nev.viev.osc.nttffl 1 1 
osc2oap.oap.idx !* i; 

25 end 

/* abort branch is not taken */ 

find > 0 oapdb in RLoapdb 

where (oapdb . oap.num nev.viev.oap.numCi]) 

30 end 

end 
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Claims 



1. Apparatus for generating code for a transaction on a set of data, the transaction being subject to con- 
straints and 

40 the apparatus comprising: 

a transaction description of the operations of the transaction, the operations including at least one 
operation which nray abort without affecting the set of data; 

a constraint specification for specifying the constraints: and 

code generating means responsive to the transaction description and the constraint specification 
45 for generating the code, the code generating means including 

means for generating code for an update constraint which indicates whether the constraints would 
be satisfied if the transaction could not abort. 

2. The apparatus set forth in daim 1 wherein: 

50 the system In which the code is executed has an application level and a system levsl; 

the code for the update constraint runs at the application level; and 
the operation aborts at the system level. 

3. The apparatus set forth in either claim 1 or 2 wherein: 

the means for generating code generates code for an update constraint which is a weakest pre- 
condition. 

4. The apparatus set forth in either daim 1 or 2 wherein: 
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the transaction is an update transaction which altars the set of data. 

5. The apparatus set forth in either dalm 1 or 2 wherein: 
the apparatus is implemented In a data base system; and 
the transaction is an update transaction of the data base system. 

6. A nnethod of making apparatus for performing a transaction on a data set* the transaction being subject 
to constraints and involving an operation which may abort, 
the method comprising the steps o^ 

computing from the constraints and a description of the transaction an update constraint which 
indicates whether the constraints would be satisfied if the transaction could not abort; and 

generating code which is executed during the transaction and which determines whether the up- 
date constraint is satisfied. 

7. The method set forth in claim 6 wherein: 
the operation which may abort aborts at a system level; and 
the step of generating code generates code which Is executed at the user level. 

8. The method set forth in either claim 6 or daim 7 wherein: 
the step of generating code generates code for an update constraint which is a weakest precondi- 
tion. 

9. A method of performing a transaction on a set of data, the transaction being subject to constraints and 
Involving an operation which may abort, the method having the improvement comprising the step of: 

prior to altering the set of data, testing an update constraint which, when satisfied, indicates wheth- 

29 er the constraints would be satisfied If the transaction could not abort, and not altering the set of data if 
the update constraint is not satisfied. 

10. A data base system for performing transactions on a set of data, the transactions being subject to con- 
straints, the transactions induding an operatton whteh may abort without affecting the set of data, and 

30 the database system having the improvement comprising: 

means for ensuring the integrity of the set of data by testing an update constraint which, when sat- 
isfied, Indicates that the constraints would be satisfied if the operation could not abort and not altering 
the set of data if the update constraint is not satisfied. 

38 
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FIG. 3 

Examples 

employees(name. salary, dept) 
departments(dept. manager) 



Constraints! 

I. Ve € employees 

min < csalary A e.salary < max J 30i 



1 303 



2. Vc € employees 3d € departmenta 1 
d.dept = e.dcpf / 

3. 6 departments Se € employees ) . 
d.manager = e.namc A d.dept = e.dept J 

L Vei € employees Ve2 € employees Vd 6 deportment j 
(d.rfejrt = ei.dept A e^ name = d.manager) f 309 

-» e^.^o/ary < e2^salary J 



nG.5 

Example 1 

505 

input: ^ 

/itre(n, <<p) = in jcrttemp/oyeej, (n, j, dp}) 403 
501 

503 

output: 

hire{n,s,dp) = 

if min <s As < max A 

{Bd € (iepartmefilj d.dept = <fp)A ^ SIS (407) 

(Ve € employees V<i € <iepartment3 
^^^1 ((<.<<ept =s dp A d.mana^er = e.name) 

J < e.joiary) 

then tnjert(emp/oyeej. (n, j, dp)) 1^ 
else ertor 
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